What are some of the limitations of use cases and use case specifications?

Vineet Banwet — Fri, 06 Feb 2009 05:00:00 GMT

Use cases are a valuable tool available to the business analyst for documenting functional requirements of a system or business, however they do have limitations.

Use cases were not created to capture non-functional requirements (e.g performance, platform, scalability, reliability of a system). While use case specification templates have been extended by some in an ad-hoc fashion to list non-functional requirements, this strays from the intended purpose of a use case. Use cases are functional in nature. It is this very organization by function that give use cases their many benefits. Arbitrarily listing non-functional requirements in one use case specification or another can obfuscate the cohesiveness and benefits of the use case specification.
The non-sequential nature of a use case diagram is often difficult for some audiences to understand. When one use case includes or extends another, the reader of the diagram often arrives at the incorrect conclusion that the use case diagram is showing a sequence where the first use case is completed before the other begins. Those who are familiar with use case diagrams know that an included or extended use case can occur or be initiated at any point within the including or extending use case.
Learning how to write use cases takes time. Many consider it to be more of an art than a science. This is because there is no fully defined set of standards for how to write use cases, or what should be included within a use cases specification. And while there have been many different views espoused by authors, still a great deal of commonality has emerged among them. Where this commonality exists there is little disagreement among use case writers and those who consume or read use cases. However, in some areas there are still a number of differing opinions creating confusion for new use case authors. Because of this, the learning curve for use cases and use cases specifications is elongated. Still, over time, use case authors and readers develop a more sophisticated understanding of those areas that are more ambiguous and open for interpretation, such as the “extends” relationship.
Use case specifications are not an appropriate tool for describing the user interface of the application. Use cases should be left as UI independent as possible. Remember that a use case specification it intended to capture the functional requirements of the system, or in other words, WHAT the system should do in response to a user action. This is very different than HOW the system should do something. Any time an analyst captures requirements, the focus should be on the WHAT not the HOW. This gives the system and UI designer the freedom to develop the best solution possible. It also makes our use case specifications much more maintainable since a change in screen design doesn’t impact the user-system interaction previously defined.

What is the difference between a use case specification and a use case realization ?

Vineet Banwet — Tue, 06 Jan 2009 16:16:00 GMT

A Use Case Specification is a textual description of the functionality provided by the system. It captures actor-system interaction. That is, it specifies how a user interacts with a system and how the system responds to the user actions. It is often phrased in the form of a dialog between the actor and the system. The use case specification is represented in the use case diagram by an oval, and is what most people think of when they hear the term use case.

A Use Case Realization describes how a use case, which is logically defined by the use case specification, is physically implemented within a design model in terms of collaborating objects. It organizes the design model artifacts related to the use case. It often comprises multiple design artifacts such as a class diagram, object diagram, sequence diagram, etc. that describe how the physical design will implement the use case specification.

The purpose of use case realization is to separate the concerns of the system stakeholders, which are typically captured by the use case model and system requirements, from the concerns of the system designers. In doing so, the designers can choose to implement the use case specification without affecting the use case specification.

Business Analyst Community & Resources | Modern Analyst

What are some of the limitations of use cases and use case specifications?

What is the difference between a use case specification and a use case realization ?